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INTRODUCTION 


OBJECTIVE. 

The  overall  objective  of  this  testing 
was  to  evaluate  the  ability  of  the 
Discrete  Address  Beacon  System  (DABS) 
en  route  air  traffic  control  (ATC)  Build 
I  system  to  simultaneously  accept, 
process,  track,  and  display  DABS  and  Air 
Traffic  Control  Radar  Beacon  System 
(ATCRBS)  surveillance  data  from  one  DABS 
sensor  and  multiple  ATCRBS  sensors. 

BACKGROUND. 

The  en  route  National  Airspace  System 
(NAS)  model  A3d2.4  software  system, 
hereafter  referred  to  as  A3d2.4,  was 
modified  by  the  Computer  Sciences 
Corporation  to  provide  the  capability  of 
processing  DABS  message  formats  and 
information  content.  The  revised 
system,  hereafter  referred  to  as  the 
Build  I  system,  was  designed  to  simul¬ 
taneously  interface  with  both  the  DABS 
and  ATCRBS  sensors.  The  Build  I  soft¬ 
ware  provides  for  tracking  of  surveil¬ 
lance  data  from  a  single  DABS  sensor 
and  multiple  ATCRBS  sensors.  Included 
in  the  software  is  the  capability 
to  process  surveillance  related 
communication  messages. 

The  Build  I  system  is  for  developmental 
purposes.  It  is  used  in  the  En  Route 
System  Support  Facility  (ESSF)  at  the 
Federal  Aviation  Administration  (FAA) 
Technical  Center  and  interfaces  with  any 
one  of  the  DABS  engineering  models 
located  at  the  Technical  Center  and 
Elwood  and  Clementon,  New  Jersey. 


DISCUSSION 


DESCRIPTION  OF  EQUIPMENT. 

Build  I  system  technical  tests  were 
conducted  using  simulated  inputs  derived 
from  two  configurations.  The  first 


employed  a  direct  interface  between  the 
DABS  sensor  and  the  ESSF  using  the  Air¬ 
craft  Reply  and  Interference  Environment 
Simulator  (ARIES)  as  inputs  to  the  DABS. 
ARIES,  in  turn,  used  test  scenarios 
containing  target  files  generated 
off-line  by  the  Air  Traffic  Control 
Simulation  Facility  (ATCSF).  The  second 
configuration  employed  the  DABS  simula¬ 
tion  (DABS1M)  subprogram  which  generated 
DABS  data  simulation  tapes  off-line  for 
input  to  the  Build  I  system. 

EN  ROUTE  SYSTEM  SUPPORT  FACILITY.  This 
facility  is  used  to  support  air  route 
traffic  control  center  (ARTCC)  testing. 
It  can  simulate  any  of  the  20  ARTCC's. 
The  major  elements  of  this  facility  are 
the  9020  NAS  stage  A  computer  complexes, 
remote  C  system  (Job  Shop),  computer 
display  channel  (CDC) ,  display  channel 
complex  (DCC) ,  print  station,  computer 
update  equipment  (CUE),  data  receiver 
group  (DRG),  NAS  en  route  laboratory, 
and  the  radar  distribution  center.  A 
detailed  description  of  the  ESSF  can  be 
found  in  NAS  document  No.  NASP-5204-01 
(volumes  I  and  II),  "Hardware  Environ¬ 
ment  and  Support  Services,"  June  1979. 

DISCRETE  ADDRESS  BEACON  SYSTEM  SENSOR. 
This  system  consists  of  three  major 
subsystems:  the  interrogator  and  proces¬ 
sor  (I&P)  subsystem,  the  computer 
subsystem,  and  the  communications 
subsystem.  A  fourth  subsystem,  the  data 
extraction  subsystem,  extracts  data 
produced  by  the  major  subsystems  of  the 
sensor.  A  detailed  description  of  the 
DABS  sensor  is  defined  in  the  Department 
of  Transportation  FAA  Engineering 
Requirement  FAA-ER-240-26 . 

FRONT  END  PROCESSOR.  The  front  end 
processor  CFEP )  subsystem  provides  a 
separate  bidirectional,  full  duplex 
communication  interface  to  the  Build  I 
system  for  each  DABS  sensor.  The 
interface  uses  unconditioned  telephone 
circuits  with  4,800  bits  per  second 
(bps)  modems  to  transfer  status,  con¬ 
trol,  and  operational  ATC  messages.  In 
addition,  the  FEP  performs  a  translation 
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between  the  Common  International  Civil 
Aviation  Organization  (ICAO)  Data 
Interchange  Network  (CIDIN)  protocol  and 
the  Build  I  protocol. 

AIRCRAFT  REPLY  AND  INTERFERENCE 
ENVIRONMENT  SIMULATOR.  The  ARIES  was 
designed  by  Lincoln  Laboratory  to 
simulate  DABS/ATCRBS  target  replies, 
ATCRBS  fruit  replies,  communications 
(COMM)  messages,  and  radar  data.  The 
interrogation  interface  between  the 
sensor  and  the  ARIES  was  at  the  radio¬ 
frequency  (RF)  level.  The  replies 
generated  by  the  ARIES  were  inputted  to 
the  DABS  at  the  receiver  intermediate 
frequency  (IF)  level.  Radar  interface 
was  accomplished  via  the  DABS  communica¬ 
tion  subsystem  as  normally  accomplished 
for  radar. 

Along  with  the  simulated  traffic  the 
ARIES  generated  a  simulated  fruit 
environment.  The  arrival  times  of  fruit 
replies  were  not  based  on  the  traffic 
model.  To  do  this  would  also  require 
modeling  the  nearby  interrogators  that 
cause  these  interfering  replies  to  be 
generated.  Instead,  fruit  was  modeled 
as  a  random  process  with  Poisson 
statistics.  The  operator  can  control 
the  average  fruit  rate  by  setting 
parameters  in  a  file  on  the  system 
disk. 

The  ARIES  is  capable  of  generating 
ATCRBS  fruit  replies  at  rates  up  to 
about  50,000  replies  per  second.  These 
high  rates  were  required  to  test  the 
performance  of  the  DABS  sensor's  reply 
processing  circuitry  at  the  interference 
levels  at  which  it  is  capable  of 
operating. 

For  both  the  simulated  transponder 
(controlled)  replies  and  fruit  replies, 
the  ARIES  provides  the  necessary  signals 
to  accurately  simulate  the  monopulse 
of f-boresight  angle.  Also,  an  omni¬ 
directional  signal  was  provided  so  that 
aide-lobe  replies  could  be  simulated. 
These  signals  were  connected  to  the  DABS 
sensor  via  an  interface  dedicated  to  the 


ARIES.  The  sensor  added  these  signals 
to  similar  signals  from  the  sensor's 
antenna.  This  allowed  a  simulated 
environment  to  be  superimposed  on  a  live 
environment . 

A  maximum  of  400  targets  can  be  simula¬ 
ted  by  the  ARIES.  Any  mix  of  DABS  and 
ATCRBS  targets  are  possible.  In  addi¬ 
tion  to  the  beacon  data,  the  ARIES 
provided  simulated  digitized  radar  data 
in  the  output  format  of  the  common 
digitizer  (CD).  The  radar  targets 
correlate  to  the  simulated  beacon 
targets.  The  reported  coordinates  were 
those  seen  by  a  primary  radar  whose 
antenna  rotates  with  the  beacon  antenna 
about  the  same  axis.  The  ARIES  operator 
can  control  the  radar  reply  probability 
by  setting  parameters  in  file  on  the 
system's  disk. 

The  ARIES  equipment  consists  of  inter¬ 
rogation  receiving  circuitry,  reply 
generation  circuitry,  and  a  computer 
with  associated  peripheral  equipment  to 
control  the  system.  This  equipment  is 
housed  in  two  standard  racks.  A  com¬ 
plete  description  of  the  simulator  is 
contained  in  report  No.  FAA-RD- 78-96 , 
"The  Aircraft  Reply  and  Interference 
Environment  Simulator  (ARIES),"  (volume 
1,  Principles  of  Operation,  volume  2, 
Appendices  to  the  Principles  of  Opera¬ 
tion,  and  volume  3,  Programmers  Manual). 

AIR  TRAFFIC  CONTROL  SIMULATION  FACILITY. 
This  facility  uses  Sigma  5  and  Sigma  8 
computers  and  an  associated  minicomputer 
(Alpha-16)  to  provide  the  following 
funct ions: 

1.  Aircraft  flight  generation/ 
simulation 

2.  Radar  and  beacon  simulation 

3.  ATC  simulation 

4.  Pilot  simulation 

The  simulation  software  has  been 
designed  to  accommodate  up  to  300 


simultaneous  simulated  targets,  480 
navigational  aids  or  fixes,  and  700 
route  segments.  A  capability  to  emulate 
the  functions  of  the  DABS  sensor  and 
three  ATCRBS  sites  have  been  developed. 
A  detailed  description  of  the  ATCSF  can 
be  found  in  the  "User's  Guide  for 
Digital  Simulation  Facility  at  NAFEC," 
CSE-R-170,  September  15,  1972. 

METHOD  OF  APPROACH. 

The  Build  1  system  was  tested  using  two 
equipment  configurations.  The  first 
configuration,  illustrated  in  figure  1, 
provides  only  DABS  coverage  and  involved 
the  ARIES  generating  simulated  aircraft 
replies  as  a  result  of  DABS  sensor 
interrogations  and  the  prescripted 
traffic  scenario  tape  generated  by  the 
ATCSF.  The  surveillance  data  lines 
transfer  the  surveillance  data  from  the 
DABS  sensor  to  the  ESSF  via  the  data 
receiving  equipment  (DRE) . 

DABS  has  an  effective  scan  rate  of  4.8 
seconds  that  is  achieved  for  en  route 
facilities  by  the  use  of  two  beacon 
antennas  mounted  in  a  back-to-back 
configuration.  Normally,  en  route 
ATCRBS  sites  employ  a  scan  rate  of  10  or 
12  seconds.  A  full-duplex  communication 
message  transfer  line  is  utilized 
which  employs  CIDIN  protocol  via  the 
FEP . 

The  second  conf igurat ion,  illustrated  in 
figure  2,  involves  ATCRBS  surveillance 
data  generated  by  direct  simulation  and 
processed  by  the  A3d2 .4  system;  DABS  and 
ATCRBS  surveillance  data  were  generated 
by  direct  "DABS  Simulation  (DABSIM)," 
CSC/TM-78 16046 ,  and  processed  by  the 
Build  I  system. 

A  series  of  tests  was  conducted  to 
compare  the  Build  I  system  performance 
with  the  A3d2.4  system.  The  following 
areas  were  evaluated: 

1.  Track  initiation 

2.  Track  continuity 


3 .  Track  swap 

4.  Input  processing  of  DABS  surveil¬ 
lance  data  formats 

5.  Processing  of  the  DABS  modified 
flight  plan  and  flight  related  messages 

In  addition,  the  following  communication 


messages  were 

evaluated : 

1. 

ATCRBS  identification  (ID) 

request 

2. 

ATCRBS  ID 

code  message 

3. 

Message 

rejection  delay 

notice 

Testing  in  the  areas  of  track  initia¬ 
tion,  track  continuity,  track  swap,  and 
communication  messages  were  conducted 
using  simulated  surveillance  and  sur¬ 
veillance  related  communications  input 
data.  Tests  were  conducted  with  simu¬ 
lated  sensor  coverage  of  the  following 
types : 

1.  Tracks  in  ATCRBS  only  coverage  using 
direct  simulation  data. 

2.  Tracks  in  DABS  only  coverage  using 
the  ARIES  and  direct  simulated  data. 

3.  Tracks  in  both  DABS  and  ATCRBS 
coverages  using  direct  simulation  data. 

4.  Tracks  crossing  between  DABS  and 
ATCRBS  coverages  using  direct  simulation 
data. 


The  major  variables  considered  during 
testing  for  track  initiation,  track 
continuity,  and  track  swap  were: 


1.  Flightpaths. 

a. 

Straight 

1  ines 

b. 

Turns 

c . 

Aircraft 

speed 

d. 

Aircraft 

crossing  angle  for  swap 

s ituat 

ions 
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FIGURE  1 .  ARIES/ DABS  SENSOR/ESSF  TEST  ENVIRONMENT 
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IBM  9020 

EN  ROUTE  NAS  MODEL  A3d2.  4  SYSTEM 
EN  ROUTE  DABS/ A TC  BUILD  I  SYSTEM 
NAS  OPERATIONAL  SUPPORT  SYSTEM  (NOSS) 


FIGURE  2.  DIRECT  SIMULATION/ESSF  TEST  ENVIRONMENT 


e.  Aircraft  speed  differential  for 
swap  situations 

f.  Aircraft  altitude  differential 
for  swap  situations 

2.  DABS  beacon  with  and  without  search 
data . 

3.  ATCRBS  discrete  and  nondiscrete 
beacon  with  and  without  search  data. 

4.  Simulated  blip/scan  (b/s)  ratios  of 
100  and  75  percent. 

5.  Simulated  range  and  azimuth  jitter 
of  50  feet  and  0.1°,  respectively,  for 
direct  simulation. 

6.  Simulated  ATCRBS  fruit  rates  of 
4,000  replies  per  second  and  0  replies 
per  second  for  the  ARIES  only. 

7.  Turn  rates  of  2.4°  and  2.5°  per 
second . 

Test  scenarios  containing  the  following 
flight  patterns  were  employed: 


1 .  Straight  line 

2.  Overtaking 

3.  Tracks  crossing  at  various  angles 

4.  180°  turns 

5.  360°  turns 

Examples  of  these  scenarios  are  depicted 
in  figures  3,  4,  and  5.  Each  scenario 
was  used  for  track  initiation,  track 
continuity,  and  track  swap  analysis. 
Identical  flight  routes  were  followed  by 
simulated  aircraft  with  ATCRBS  and  DABS 
transponders.  The  first  character  of 
each  aircraft  ID  represents  the  trans¬ 
ponder  used  by  the  aircraft  (A  =  ATCRBS, 
D  =  DABS).  Figure  3  depicts  straight 
line,  overtaking,  and  180°  turn  flight 
patterns  generated  with  the  data  defined 
in  table  1  .  Figure  4  depicts  straight 
line  and  360°  turn  flight  patterns 
generated  with  data  defined  in  table  1. 
Figure  5  depicts  straight  line  and  vari¬ 
ous  angle  crossing  flight  patterns  gen¬ 
erated  with  the  data  defined  in  table  2. 
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FIGURE  3.  180°  TURN  AND  STRAIGHT  LINE  SCENARIO  FLIGHTPATHS 
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FIGURE  4.  360*  TURN  AND  STRAIGHT  LINE  SCENARIO  FLIGHTPATHS 
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FIGURE  5.  STRAIGHT  LINE  AND  CROSSING  SCENARIO  FLIGHTPATHS 


TABLE  2.  DESCRIPTION  OF  AIRCRAFT  CHARACTERISTICS  FOR  FLIGHTPATHS  ILLUSTRATED  IN 
FIGURE  5 


Aircraft 

ID 

In  it ial 
Heading 
(Degrees) 

Speed 
( Knot  s ) 

A 1 1 1 1  ude 
(  Feet  ) 

Routt* 

Type  of 
Coverage 

Hax.  Kanpe 
From  OCR 
(nini ) 

Cnmmi  ni  n 
( Si»«*  Notes) 

AC101 

353 

ISO 

16,000 

B 

ATCRBS 

IHb 

ATCRBS  equipped,  inwai's  with  AC  102 

AC  102 

1 1 

ISO 

lb, 000 

A 

ATCRBS 

200 

ATCRBS  equipped,  irossen  with  ACIOI 

AC101 

IS) 

ISO 

lb, 000 

B 

ATCRBS 

1B6 

ATCRBS  equipped,  crosses  with  DC 104 
trails  ACIOI  hy  2.5  mmi 

ncl«>4 

1  1 

ISO 

lb, 000 

A 

ATCRBS 

200 

DABS  equipped,  i rosges  with  ACI03, 
trailn  AC 102  by  2,5  mat 

IS  1 

ISO 

1 b ,000 

H 

ATCRBS 

1Kb 

DABS  (‘quipped,  crosses  with  DC1 06  , 

(  mi  Ik  AC  103  hy  2.5  nm 

tv  l  On 

1 1 

ISO 

1 h ,000 

A 

AICRMS 

200 

DABS  equipped,  croggeg  with  DC  105, 
f  i  .1 «  1  k  IK' 104  hy  ?.S  unit 

AC  10/ 

1  4 

100 

IS, 000 

i' 

1»A  BS 

90 

ATCKRS  equipped,  flosses  with  AClOK 

AClOK 

)•♦  s 

100 

IS, 000 

l> 

DABS 

K2 

ATCRBS  equipped,  c rosses  with  ACI07 

AC  1 0‘» 

14 

300 

IS, 000 

C 

DABS 

90 

ATCRBS  equipped,  crosses  with  DCl 10 
trails  AC  107  by  5  nmi 

DC  l  1 0 

14  S 

loo 

IS, 000 

0 

OARS 

H? 

DABS  equipped,  crosses  with  AC 109, 
trails  AClOK  hy  5  nmi 

DC  III 

14 

100 

IS, 000 

c 

DABS 

40 

OAKS  equipped,  crosses  with  DCl 12, 
t  rai Ik  AC 1 09  hv  5  nmi 

IV  |  1.’ 

14  S 

100 

IS, ooo 

n 

UAHS 

H.> 

DABS  equipped,  crosses  with  Di’lll, 
t  t  at  1  h  DC l  1 0  by  5  nm i 

AC  1  1  1 

|4 

son 

.’0,000 

h 

DABS/ 

ATCRBS 

1  14 

ATCRBS  equipped,  crosses  with  AC1 14 

AC  1  14 

no 

S 1  * 

20,000 

V 

OARS/ 

ATCRBS 

4h 

ATCRBS  equipped,  C tosses  with  ACl 1 3 

Al  l  IS 

19 

soo 

20,000 

K 

OARS  f 

ATCRBS 

1  14 

ATCRBS  equipped,  crosses  with  DCl  lb 
trails  ACl 1 3  by  8.3  non 

DOJ  lb 

330 

S22 

20,000 

K 

OARS/ 

ATCRBS 

9b 

DABS  equipped,  crosses  with  ACl 15, 
trails  ACl 14  by  8.3  nmi 

DC  1 1  7 

19 

SOO 

20,000 

K 

OAKS/ 

ATCRBS 

1  14 

DABS  equipped,  crosses  with  DCl 18, 
trails  ACl 15  by  8.3  nmi 

DC1I8 

no 

522 

20,000 

F 

DABS/ 

ATCRBS 

9b 

DARS  equipped  crosses  with  DCl 17, 
trails  DC  1 1 b  by  8.3  nmi 

NOTES : 

1.  Thin  data  generated  two  scenarios: 

(a)  ATCRBS  bi*a«on  woa  discrete;  and 

(b)  ATCRBS  beacon  wan  nondiacrete. 

2.  OCR  ■  Elwtntd  senior, 

3.  All  a  ire  r  Aft  employed  ATCRBS  t  r  an s ponders  fur  ihe  A  3d?.  4  system. 
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DATA  COLLECTION. 

During  each  test,  data  were  collected 
automatically  by  the  Build  I  system 
analysis  recording  (SAR)  function.  SAR 
extracted  surveillance,  communication, 
track,  and  flight  plan  (FP)  data  related 
to  each  tracked  target.  The  ARIES  and 
DABS  extractor  programs  were  used  to 
verify  ARIES  surveillance  data  inputs  to 
the  DABS  sensor  and  DABS  surveillance 
and  communications  data  outputs  to  the 
ESSF. 

DATA  REDUCTION. 

Data  were  reduced  off-line  by  the  ESSF 
for  subsequent  analysis.  The  following 
programs  were  processed  by  the  ESSF  to 
reduce  the  SAR  tapes  generated  by  the 
Build  I  system. 

1.  "Data  Analysis  and  Reduction  Tool 
(DART),"  CSC/TM-79/6247 ,  support  program 
reduces  SAR  data  for  analysis  in  accord¬ 
ance  with  the  following  user  requested 
functions : 

a.  Log  function  —  input/output  of 
all  activity  in  the  Build  I  system. 

b.  History  function  —  chronologi¬ 
cal  history  of  correlations  for  speci¬ 
fied  tracks  in  the  Build  I  system. 

c.  Track  function  —  provides  a 
time-ordered  listing  of  the  track  data 
base  by  aircraft  and  a  summary  of 
information  describing  the  average 
performance  of  the  tracks  in  the  Build  I 
system. 

2.  Interface  verification  off-line 
data  reduction  and  analysis  program 
preprocessor  (DIVARP)  reduces  SAR 
tapes  to  produce  an  output  tape  with 
communication  data  and  an  output  tape 
with  surveillance  data  to  be  further 
processed. 

3.  Interface  verification  off-line  data 
reduction  and  analysis  program  (DIVAR) 
reduces  DIVARP 's  output  tapes  to  produce 


surveillance  summary  reports  and  com¬ 
munications  summary  reports. 

Additionally,  data  reduction  programs 
developed  by  ACT-100  and  ACT-700  for 
the  Honeywell  series  66/60  and  Digital 
Equipment  Corporation  (DEC)  PDP-11  com¬ 
puters  were  used  to  assist  in  analysis 
by  generating  plots  of  required  data  and 
listings  of  unprocessed  and  processed 
data. 


RESULTS  AND  ANALYSIS 


DIRECT  SIMULATION/BUILD  I. 

This  series  of  tests  concerns  only  the 
surveillance  data  processing  and  track¬ 
ing  function.  The  overall  objective  was 
to  provide  an  initial  assessment  of  the 
performance  of  the  integrated  Build  I 
software  package.  The  primary  objective 
was  to  verify  the  ability  of  the  Build  I 
software  to  process  and  track  surveil¬ 
lance  data  and  compare  the  results  with 
those  achieved  by  the  A3d2.4  system. 
Both  systems  employed  test  scenarios 
with  identical  flight  patterns,  includ¬ 
ing  the  360*  turns  and  the  various 
angle  crossing  flights  illustrated  in 
figures  4  and  5.  The  simulation  air¬ 
craft  employed  to  fly  these  flight 
patterns  are  described  in  table  1. 

The  A3d2.4  system  processed  ATCRBS  data 
from  simulated  en  route  ATCRBS  sites, 
while  Build  I  processed  both  ATCRBS  and 
DABS  data  generated  from  simulated  en 
route  ATCRBS  sites  and  one  simulated 
DABS  sensor. 

The  initial  assessment  of  display 
observations  and  analysis  of  data 
reduction  printouts  verified  that  all 
tracks  were  properly  initiated  and  no 
track  swaps  occurred.  Initially,  a 
problem  was  encountered  that  resulted  in 
a  loss  of  tracking  for  some  turning 
tracks.  For  example,  if  a  turning 
aircraft  continued  to  correlate  with  its 
respective  track  in  the  large  search 
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area  (LSA)  for  approximately  three 
tracking  cycles,  the  track  would 
eventually  go  to  coast.  The  problem 
was  traced  to  incorrect  LSA  velocity  and 
position  adjustment  (smoothing)  in  the 
tracking  program  and  has  been  corrected. 

Analysis  of  the  Build  I  surveillance 
data  processing  and  tracking  functions 
established  the  ability  of  Build  I  to 
simultaneously  process  DABS  and  ATCRBS 
data  via  direct  simulation.  The  per¬ 
formance  data  used  to  evaluate  the 
tracking  ability  of  Build  I  were  TRACK 
DEVIATION  (the  distance  from  the  pre¬ 
dicted  track  position  to  the  time 
corrected  radar  position),  TRACK 
HEADING,  and  TRACK  SPEED  which  are 
calculated  from  the  track  velocity 
components.  These  performance  data  were 
used  to  compare  Build  I  tracking  with 
A3d2.4  tracking  for  each  aircraft 
described  in  table  1.  Aircraft  repre¬ 
sentative  of  overall  track  performance 
are  depicted  in  figures  6  through  11  and 
are  graphic  illustrations  of  these 
comparisons.  They  are  actual  plots  of 
performance  data  taken  from  a  portion  of 
a  flight  pattern  prior  to  entering  a 
turn  and  for  the  duration  of  the  turn. 
Analysis  revealed  that  the  tracking 
performance  for  heading  and  speed 
required  an  average  of  2.5  minutes  to 
stabilize  after  actual  aircraft  turn 
completion.  Acknowledged  differences  in 
performance  data  between  the  Build  I  and 
the  A3d2.4  systems  are  attributed  to: 
(1)  the  Build  I  dynamic  small  search 
area  (SSA)  function,  and  (2)  a  Build  I 
correlation  problem. 

The  Build  I  SSA  is  a  circle  centered  on 
the  predicted  track  position.  The 
radius  of  the  SSA  is  a  function  of  the 
type  of  data  being  correlated,  the 
type  of  sensor  from  which  the  data 
originated,  and  the  range  of  the  data. 
For  any  given  data  the  SSA  radius  shall 
be  determined  by  the  data  in  table  3. 
Since  the  Build  I  SSA  is  dynamic,  it  can 
be  smaller  than,  equal  to,  or  larger 
than  the  A3d2.4  SSA  which  has  a  fixed 
radius  of  1  nautical  mile  (nmi).  This 


SSA  size  difference  can  cause  given 
data  to  correlate  in  a  different  search 
area  for  each  system.  For  example,  if  a 
given  track  deviates  from  its  respective 
ATCRBS  data  by  1.1  nmi  and  the  Build  I 
SSA  is  calculated  to  be  1.2  nmi,  the 
data  will  correlate  in  the  Build  I  SSA. 
These  data  in  A3d2.4,  however,  will 
correlate  with  the  same  track  in  the  LSA 
(6-nmi  radius).  This  difference  in 
search  area  correlations  results  in 
different  velocity  component  calcula¬ 
tions  and  different  predicted  track 
positions  because  SSA  smoothing  is 
applied  in  Build  I  and  in  A3d2.4.  The 
correlation  problem  occurs  when  two 
discrete  beacon  or  DABS  reports  are 
received  from  a  DABS  sensor  in  the  same 
6-second  time  frame.  The  closest  data 
to  the  predicted  track  position  should 
be  stored  for  tracking.  However,  Build 
I  stores  the  second  data  received 
regardless  of  which  is  closest.  This 
problem  will  be  corrected  in  Build  II 
and  checked  during  Build  II  regression 
test ing. 

Excluding  the  differences  noted,  it  is 
considered  that  for  the  tests  conducted, 
the  tracking  performance  of  Build  I  is 
equal  to  the  performance  of  A3d2.4.  The 
analysis  also  revealed  that  when  the 
blip  scan  ratio  was  changed  from  100  to 
75  percent,  no  track  swaps  or  loss  of 
track  continuity  were  experienced  by 
either  system. 

Three  other  tracking  related  problems 
were  also  identified: 

1.  When  only  DABS  reports  correlated 
with  a  DABS  track  and  no  supplied  beacon 
code  was  received,  the  beacon  code 
establishment  function  was  performed. 
This  function  should  not  have  been 
activated  unless  an  ATCRBS  report  or  the 
supplied  code  was  received. 

2.  When  a  track  was  initiated  with  a 
flight  plan  speed,  the  speed  of  the 
aircraft  should  have  been  changed  from 
knots  to  1/4  knots  before  being  stored 
for  tracking.  This  did  not  occur. 
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FIGURE  6.  TRACK  DEVIATION  COMPARISON  FOR  AIRCRAFT  DTI  1  TURNING  360* 
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FIGURE  9 


TRACK  DEVIATION  COMPARISON  FOR  AIRCRAFT  DTI 2  TURNING  360 
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FIGURE  11 


TRACK  SPEED  COMPARISON  FOR  AIRCRAFT  DTI 2  TURNING  360 


TABLE  3. 


DYNAMIC  SSA  COMPUTATION  DIAGRAM  AND  PARAMETER  VALUES 


Sensor  Type 


SSA  Radius,  Use  the  Larger  of: 

Data  Type  3-Sigma  Range  Error  3-Sigma  Azimuth  Error 


DABS 

TORE 

TDAE 

/  2n  \ 

X4096/ 

DABS 

ATCRBS 

TAEE 

TAAE 

/  2  IT  \ 

\4096/ 

SEARCH 

TSRE 

TSAS  I 

/  In  \ 

\4096/ 

SEARCH 

TSRE 

TSAS 

/  2ir  \ 

ATCRBS 

V4096/ 

ATCRBS 

TSRD 

TSAZ 

/  2n  \ 

V4096/ 

Designation 

Description 

Value 

Units 

TORE 

3-Sigma  Range  Error  for  DABS 

Beacon  Data 

0.5 

(0-1, 

0.1) 

nmi 

TDAE 

3-Sigma  Azimuth  Error  for  DABS 
Beacon  Data 

3.4 

(0-9, 

0.1) 

ACPS 

TAEE 

3-Sigma  Range  Error  for  ATCRBS 
Beacon  Data 

0.5 

(0-1, 

0.1) 

nmi 

TAAE 

3-Sigma  Azimuth  Error  for  ATCRBS 
Beacon  Datum  from  DABS 

3.4 

(0-9, 

0.1) 

ACPS 

TSRE 

3-Sigma  Range  Error  for  Search 

Data 

0.5 

(0-1, 

0.1) 

nmi 

TSAS 

3-Sigma  Azimuth  Error  for  Search 
Data 

6.0 

(0-9, 

0.1) 

ACPS 

TSRD 

3-Sigma  Range  Error  for  ATCRBS 
Beacon  Data  from  ATCRBS 

0.5 

(0-1, 

0.1) 

nmi 

TSAZ 

3-Sigma  Azimuth  Error  for  ATCRBS 
Beacon  Data  from  ATCRBS 

9.0 

(0-9, 

0.1) 

ACPS 
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3.  During  analysis  of  DART  history 
option  data,  it  was  discovered  that 
surveillance  data  were  intermit¬ 
tently  being  processed  twice  during 
correlat ion. 

These  problems  are  currently  under 
investigation  by  the  contractor  and  will 
be  checked  for  resolution  during  Build 
II  regression  testing. 

DABS  SENSOR/ BUILD  I. 

Results  from  this  series  of  tests  are 
categorized  in  two  parts:  (1)  surveil¬ 
lance  data  processing  and  tracking 
including  correlation,  track  initiation, 
track  continuity,  and  track  swap;  and 
(2)  surveillance  related  communication 
data  including  ATCRBS  ID  requests  and 
ATCRBS  ID  code  response. 

In  order  to  evaluate  track  performance 
using  the  system  configuration  depicted 
in  figure  1,  it  was  necessary  to  create 
a  Build  I  direct  simulation  scenario 
containing  only  the  Elwood  DABS  sensor. 
This  system  configuration  provided 
Elwood  radar  coverage  only  (as 
illustrated  in  figure  3).  A  track 
performance  comparison  between  the 
direct  simulation  data  and  the  ARIES/ 
DABS  sensor  data  are  depicted  in 
figures  12  through  17.  These  figures 
are  plots  of  two  of  the  aircraft 
described  in  table  1  and  follow  the 
routes  depicted  in  figure  3.  The 
selected  aircraft  are  representative  of 
the  overall  system  track  performance 
achieved  for  other  aircraft  having 
similar  flightpaths. 


to  its  extreme  range  from  the  Elwood 
sensor.  Differences  in  performance  data 
are  attributed  to  the  fact  that:  (1)  the 
ARIES  scenario  tape  was  generated  with 
an  aircraft  turn  rate  of  2.5*  per  second 
while  direct  simulation  employed  a  turn 
rate  of  2. A*  per  second;  and  (2)  the 
DABS  back-to-back  antenna  configuration 
employs  a  4.8-second  effective  scan  rate 
while  direct  simulation  employs  a 
5-second  scan  rate. 

Analysis  of  data  reduction  printouts 
from  surveillance  data  processing 
further  revealed  that  a  change  of  fruit 
rate  from  0  to  4,000  fruit  replies  per 
second  did  not  affect  the  quality  and 
quantity  of  data  from  the  DABS  sensor. 

Further  analysis  revealed  that  ATCRBS 
mode  C  garble  occurred  under  certain 
conditions.  In  garble  situations, 
the  12  mode  C  code  confidence  bits 
internal  to  the  sensor  may  indicate  low 
confidence  in  some  bit  positions.  The 
sensor  indicates  this  condition  by  not 
setting  to  1  the  mode  C  bit  (bit  6)  in 
the  ATCRBS  surveillance  report.  This 
tells  the  ATC  facility  that  the  mode  C 
field  of  the  surveillance  report  con¬ 
tains  the  first  12  bits  of  the  trans¬ 
formed  code  pulse  sequence,  which  may  or 
may  not  be  valid.  The  sensor  will  only 
indicate  a  valid  mode  C  code  present 
(bit  6  =  1 )  in  the  report  when  all  the 
12  mode  C  confidence  bits  indicate  high 
confidence.  Table  2  and  figure  5, 
respectively,  describe  the  aircraft 
and  their  respective  air  routes  per¬ 
taining  to  the  following  mode  C  garble 
situations. 


The  explanation  of  track  turn  stabiliza¬ 
tion,  as  previously  noted,  also  applies 
here.  Since  range  and  azimuth  errors 
are  a  function  of  range,  tracking 
becomes  slightly  erratic  as  aircraft 
move  away  from  the  Elwood  sensor. 
Aircraft  distances  from  Elwood  are 
listed  in  table  1;  the  routes  they 
follow  are  illustrated  in  figure  3. 
Figures  15  through  17  show  the  erratic 
track  performance  of  aircraft  DT-12  due 


1.  The  first  situation  involved  air¬ 
craft  AC-101  and  AC-103  which  were 
traversing  tangential  route  B.  The  two 
aircraft  were  in  trail  and  consistently 
separated  by  0.7°  in  azimuth  relative  to 
the  DABS  sensor.  Data  samples  were 
taken  during  a  time  span  of  12  minutes. 
During  this  sample  period,  15.5  percent 


of  the  308  surveillance  messages 
received  from  the  DABS  sensor  had  their 
mode  C  field  marked  invalid  (bit  6  not 
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FIGURE  16.  TRACK  HEADING  COMPARISON  FOR  AIRCRAFT  DTI2  TURNING  180* 


set).  However,  75  percent  of  the 
invalidated  mode  C  fields  contained 
the  correct  altitude. 

2.  The  second  situation  involved  a 
third  aircraft,  AC**102,  traversing  route 
A  which  crosses  route  B.  As  AC-102 
began  to  close  with  AC-101  and  AC-103 
there  was  a  marked  increase  in  mode  C 
garble.  Samples  were  taken  during  the 
time  that  the  three  aircraft  were 
located  in  an  area  defined  by  a  azimuth 
difference  of  5.0*  and  a  range  dif¬ 
ference  of  6.8  nmi  relative  to  the  DABS 
sensor.  While  the  three  aircraft  were 
in  this  area,  35  percent  of  the  192 
surveillance  messages  received  had. their 
mode  C  data  fields  marked  invalid. 
Usually,  the  invalid  mode  C  fields 
contain  the  correct  altitude,  but  in 
this  case  only  41  percent  were  correct. 

ATCRBS  surveillance  data  containing 
beacon  codes,  not  included  on  the  ARIES 
scenario  input  tapes,  were  disseminated 
to  the  Build  I  system  as  being  valid 
(bit  5  in  the  surveillance  message  set 
high).  These  codes  were  a  result  of 
code  garbling  and  were  included  in  the 
surveillance  message  sent,  even  though 
some  of  the  confidence  bits  of  the  code 
reply  were  set  low. 

As  a  result  of  display  observation  and 
analysis  of  data  reduction  printouts 
of  surveillance  related  communications, 
it  was  verified  that  when  DABS  data  were 
initially  received,  an  ATCRBS  code 
message  was  received  a  short  time  later 
as  the  supplied  beacon  code.  The 
acceptance  of  the  ATCRBS  code  message 
indirectly  indicated  that  an  ATCRBS  ID 
request  message  was  automatically  sent 
to  the  DABS  sensor.  However,  a  problem 
in  the  support  program  DIVARP  has 
inhibited  a  complete  analysis  of 
communication  messages  to  date. 
Communication  message  analysis  will 
be  completed  in  Build  II  regression 
testing. 

Problems  that  occurred  with  response 
to  manual  ATCRBS  ID  requests  are  as 


follows:  (1)  when  a  manual  ATCRBS  ID 
request  was  input  by  the  controller  for 
an  ATCRBS-only-equipped  aircraft,  the 
error  response  received  was  not  the  one 
expected;  and  (2)  when  a  manual  ATCRBS 
ID  request  was  input  by  the  controller 
for  a  DABS-equipped  aircraft  not  in 
DABS  coverage,  an  error  response  was 
expected  but  none  was  received. 

SOFTWARE  EVALUATION. 

An  inspection  of  the  program  code 
revealed  that  in  order  to  locate  the 
flight  plan  associated  with  a  DABS 
address,  a  new  DABS  address  compool 
table  (DB)  and  a  new  DABS  address  table 
handler  (SDT)  were  incorporated  in  the 
Build  I  system.  For  automatic  track 
initiation,  approximately  200  instruc¬ 
tions  were  needed  to  associate  the  DABS 
address  with  the  correct  flight  plan  as 
opposed  to  17  instructions  for  a 
discrete  beacon  code.  For  DABS  correla¬ 
tion  after  automatic  track  initiation, 
87  instructions  were  needed  to  find  the 
associated  flight  plan  as  opposed  to  17 
for  discrete  beacon  code  correlation. 
It  should  be  noted  that  these  additional 
instructions  are  executed  for  each  DABS 
report  to  determine  if  the  aircraft  has 
a  flight  plan.  This  method,  while  being 
functionally  correct,  is  very  time 
consuming. 

The  current  method  of  managing  table  DB 
requires  a  series  of  locks  to  be  set 
by  programs  working  in  the  table.  While 
this  method  is  currently  employed  in 
table  management,  the  type  of  lock  being 
used  is  not  appropriate  for  use  with 
real-time  radar  processors.  The  lock  in 
question  is  the  test  and  set  instruction 
(TS),  which  cannot  be  released  if  the 
program  that  issued  the  TS  instruction 
is  interrupted  and  suspended.  The 
system  test  and  set  (TSLOK)  supervisor 
call  (SVC)  provides  the  same  service  as 
the  TS  instruction,  with  the  guarantee 
that  the  program  holding  the  lock  cannot 
be  interrupted  and  suspended.  If  the  TS 
instruction  is  not  replaced,  or  a  new 
method  of  table  management  is  not  found. 


a  timeout  abort  in  the  beacon  primary 
radar  message  processor  (RTG)  is 
possible. 

The  method  by  which  RTG  interfaces  with 
the  ATCRBS  ID  message  interface  sub¬ 
program  (CAI)  is  unnecessarily  time 
consuming.  This  method  makes  unneces¬ 
sary  use  of  the  SVG,  which  should  be 
kept  at  an  absolute  minimum  for  critical 
real-time  programs  such  as  RTG. 

The  Build  1  tracking  algorithm  makes  no 
use  of  LSA  correlations  in  the  first 
half  (1st  subcycle)  of  the  12-second 
tracking  cycle.  The  result  is  a  loss  of 
half  the  LSA  correlations  for  tracking 
involving  surveillance  data  from  the 
DABS  sensor  since  DABS  has  an  effective 
scan  rate  of  4.8  seconds. 


SUMMARY  OF  RESULTS 


TRACKING. 

1.  Test  results  indicate  100  percent 
track  initiation,  no  track  swaps,  and  no 
loss  of  tracking  for  blip  scan  ratios  of 
75  percent  and  100  percent.  This  also 
held  true  for  ATCRBS  fruit  rates  between 
0  and  4,000  replies  per  second. 

2.  Track  continuity  was  100  percent  for 
both  Build  I  and  en  route  model  A3dZ.4 
systems,  although  there  were  slight 
differences  in  the  velocity  computations 
between  the  two  systems.  The  dif¬ 
ferences  in  velocity  computations  are 
attributed  to  the  dynamic  small  search 
area  (SSA)  function  of  Build  I,  and  a 
Build  I  correlation  problem  which  is 
explained  below  in  item  1  of  the 
Surveillance  Processing  results. 

3.  The  beacon  code  establishment 
function  was  improperly  activated  on 
DABS  class  tracks. 

4.  Flight  plan  speed  was  stored  for  the 
track  in  knots  instead  of  the  required 
1/4  knots. 


SURVEILLANCE  PROCESSING. 

1.  When  two  discrete  ATCRBS  or  two  DABS 
reports  are  received  in  the  same  sub¬ 
cycle  from  the  same  aircraft,  Build  I 
always  uses  the  second  data  for  tracking 
instead  of  the  closest  return  to  the 
predicted  track  position  as  specified. 

2.  Intermittent  processing  of  the  smae 
data  twice  was  discovered  during  the 
analysis  of  data  for  the  Build  I  system. 

3.  Of  308  surveillance  messages 
received  from  the  DABS  sensor  for  two 
closely  spaced  ATCRBS  aircraft,  15.5 
percent  had  their  altitude  (mode  C)  data 
field  marked  invalid.  However,  75 
percent  of  the  invalidated  mode  C  fields 
contained  the  correct  altitude. 

4.  For  a  situation  involving  three 
closely  spaced  aircraft,  35  percent  of 
192  surveillance  messages  received  from 
the  DABS  sensor  had  an  indication  of 
invalid  mode  C  data.  However,  only  41 
percent  of  the  invalidated  mode  C  fields 
contained  the  correct  altitude. 

5.  Beacon  codes  not  included  in  the 
ARIES  scenario  were  validated,  bit  5  set 
high,  and  included  in  the  surveillance 
message  to  the  Build  I  system,  even 
though  a  number  of  DABS  sensor  confi¬ 
dence  bits  were  set  low. 

SURVEILLANCE  RELATED  COMMUNICATIONS. 

1.  ATCRBS  ID  requests  were  automa¬ 
tically  transmitted  for  all  initiated 
tracks. 

2.  When  a  manual  ATCRBS  ID  request 
was  input  by  the  controller  for  an 
ATCRBS-equipped  aircraft,  the  error 
response  received  was  not  the  one 
expected. 

3.  When  a  manual  ATCRBS  ID  request 
was  input  by  the  controller  for  a 
DABS-equipped  aircraft  not  in  DABS 
coverage,  an  error  response  was  not 
received. 
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SOFTWARE  EVALUATION. 

1.  An  inspection  of  program  code 
revealed  that  in  order  to  perform  DABS 
automatic  track  initiation,  approxi¬ 
mately  200  computer  instructions  were 
needed  as  compared  to  17  instructions 
for  discrete  beacon  automatic  track 
initiation. 

2.  For  DABS  correlation  after  auto¬ 
matic  track  initiation,  87  instruc¬ 
tions  were  needed  as  compared  to  17  for 
discrete  beacon  correlation  resulting  in 
increased  central  processing  unit 
utilization. 

3.  The  current  method  of  managing  the 
new  DABS  address  compool  table  (DB) 
requires  a  series  of  locks  that  could 
cause  a  timeout  abort  in  the  beacon 
primary  RTG. 

4.  RTG  currently  uses  SVC  routines  and 
shared  or  pool  storage  for  its  interface 
with  the  ATCRBS  ID  CAI .  The  results 
from  this  type  of  interface  is  that  RTG 
can  only  issue  one  ATCRBS  ID  request  per 
execution. 

5.  Half  of  the  LSA  correlations  of 
surveillance  data  received  from  the  DABS 
sensor  are  not  used  by  the  Build  I 
tracking  algorithm.  This  is  due  to 
exclusive  use  of  LSA  correlations  for 
smoothing  and  prediction  in  the  second 
half  (2nd  subcycle)  of  the  Build  1 
tracking  cycle. 


CONCLUSIONS 


It  is  concluded  that  the  en  route 
Discrete  Address  Beacon  System  (DABS) 
air  traffic  control  (ATC)  Build  I 
software  as  implemented  and  tested 
accepts,  processes,  tracks,  and  displays 
DAB8  and  Air  Traffic  Control  Radar 
Beacon  System  (ATCRBS)  surveillance  data 
from  one  DABS  and  multiple  ATCRBS 
sensors.  In  addition,  no  degradation  to 


the  baseline  functions  of  the  en  route 
National  Airspace  System  (NAS)  model 
A3d2.4  software  system  was  detected. 

Specific  conclusions  are  as  follows: 

1.  The  requirement  that  the  DABS 
sensor  mode  C  altitude  validation 
indicator  (bit  6)  within  the  ATCRBS 
surveillance  message  to  an  ATC  facility 
be  set  only  when  all  12  altitude 
high  confidence  bits  are  set  is 
inadequate.  In  most  cases,  the 
invalidated  mode  C  field  contains  the 
correct  altitude. 

2.  Setting  the  DABS  sensor  mode  3/A 
validation  indicator  (bit  5)  within 
the  ATCRBS  surveillance  message  to 
the  ATC  facility  whenever  any  mode 
3/A  reply  correlates  to  a  report 
is  not  adequate.  An  excessive  number 
of  ATCRBS  surveillance  messages  contain 
a  garbled  beacon  code  with  the 
mode  3/A  valid  indicator  incorrectly 
set . 

3.  The  method  employed  for  correlating 
a  DABS  target  to  a  Build  I  DABS  track, 
while  being  functionally  correct,  is 
very  time  consuming. 

4.  The  current  interface  between 
the  beacon  primary  radar  message 
processor  (RTG)  and  the  ATCRBS  identi¬ 
fication  (ID)  message  interface  sub¬ 
program  (CAI)  is  too  time  consuming  and 
limits  RTG  to  only  one  ATCRBS  ID  request 
per  execution. 

5.  The  use  of  the  test  and  set  (TS) 
instruction  as  a  technique  to  manage 
access  to  the  DABS  address  compool 
table  (DB)  could  cause  a  timeout  abort 
in  RTG. 

6.  The  use  of  all  large  search 
area  (LSA)  correlations  would  allow 
earlier  turn  detection  by  the  Build  I 
tracker  and  possibly  improve  velocity 
performance  during  turns. 


RECOMMENDATIONS 


Based  on  the  results  of  the  test  and 
evaluation  of  the  en  route  Discrete 
Address  Beacon  System  (DABS)/Air  Traffic 
Control  (ATC)  Build  I  system,  it  is 
recommended  that: 

1.  An  investigation  to  evaluate  the 
values  of  the  discrete  large  search 
area  (LSA)  smoothing  parameters, 
currently  being  used  for  discrete  and 
DABS  correlations  from  a  DABS  sensor,  be 
conducted.  Also,  evaluate  the  merits  of 
smoothing  LSA  correlations  at  the  end  of 
each  subcycle,  rather  than  the  end  of 
the  2nd  subcycle,  for  DABS  and  discrete 
data  received  from  the  DABS  sensor. 

2.  Evaluate  the  efficiency  of  the 
current  Build  I  DABS/corre lat ion 
algorithm.  A  parallel  effort  should  be 
conducted  to  establish  the  method  of 
allocating  the  DABS  addresses.  This 
would  aid  in  identifying  an  improved 
algorithm  for  DABS  correlation. 

3.  Eliminate  the  use  of  the  test  and 
set  (TS)  instruction  as  a  lock  for 
compool  table  DB  management  and  replace 
it  with  the  supervisor  call  (SVC)  TSLOK 
monitor  service. 


4.  Replace  the  current  method  of 
communicating  an  automatic  ATCRBS 
ID  request  from  beacon  primary 
radar  message  processor  (RTG)  to 
the  ATCRBS  ID  message  interface  sub¬ 
program  (CAI).  The  current  method 
uses  the  reserve,  lease,  and  send 
SVC's,  and  is  limited  to  processing 
one  ATCRBS  ID  request  per  execution 
of  the  RTG.  A  more  efficient  method 
of  processing  ATCRBS  ID  requests  would 
be  to  use  a  compool  table  controlled 
by  the  RTG  with  an  SVC  demand  to 
the  CAI. 

3.  Modify  the  criteria  for  establish¬ 
ing  an  indication  of  valid  mode  C 
altitude  (bit  6)  in  the  surveillance 
message  from  the  DABS  sensor  by 
establishing  the  rules  that:  (1)  all 
altitude  high  confidence  bits  be  set, 
or  (2)  the  altitude  be  within  4-200 
feet  of  the  last  correlated  track 
alt itude. 

6.  The  DABS  sensor  mode  3/A  code 
validation  indicator  (bit  5)  of  the 
ATCRBS  surveillance  message  should 
be  set  only  when  all  high  confidence 
bits  are  set  or  the  target  correlates 
with  an  existing  track  which  has  high 
confidence. 


